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The embedding of self-organizing inter-agent processes in distributed software applications enables 
the decentralized coordination system elements, solely based on concerted, localized interactions. 
The separation and encapsulation of the activities that are conceptually related to the coordination, is 
a crucial concern for systematic development practices in order to prepare the reuse and systematic 
integration of coordination processes in software systems. Here, we discuss a programming model 
that is based on the externalization of processes prescriptions and their embedding in Multi-Agent 
Systems (MAS). One fundamental design concern for a corresponding execution middleware is the 
minimal-invasive augmentation of the activities that affect coordination. This design challenge is 
approached by the activation of agent modules. Modules are converted to software elements that 
reason about and modify their host agent. We discuss and formalize this extension within the context 
of a generic coordination architecture and exemplify the proposed programming model with the 
decentralized management of (web) service infrastructures. 



1 Introduction 

Self-Organization describes adaptive processes among system elements, as found in physical, biological, 
and social systems, that establish and maintain structures [19]. The utilization of self-organization prin- 
ciples is an alternative approach for the construction of self-adaptive, distributed software systems [23]. 
This approach is attractive, as it allows to embed adaptive properties in the interplay of system entities. 
Consequently, centralized responsibilities are avoided that may imply bottle necks and single points of 
failure. Self-organizing system phenomena are governed by feedback loops, i.e. circular interdependen- 
cies among system elements (e.g. discussed in 111). Unlike the control loops in self-managing software 
systems [5], the loops are decentralized, i.e. distributed among system elements. 

In the research project "Selbstorganisation durch Dezentrale Koordination in Verteilten Systemen'Q 
(Sodeko VS), the utilization of self-organizing inter-agent processes as reusable design elements is stud- 
ied ll29l . Distributed feedbacks, as structures of mutual influences among system elements, are elevated 
to discrete design elements. These structures are used to define inter-agent processes and a corresponding 
programming model can be used to integrate these processes in agent-based software systems. A founda- 
tional building block is a middleware layer that provides an execution context for the process enactment 
and integration ll29l (see Section[3]). 

A key design criterion is that adaptive features can be supplemented to functioning sets of soft- 
ware agents, i.e. Multiagent Systems (MAS). Developers can add decentralized coordination, i.e. the 
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self-organization of system aspects, to working systems. A prerequisite is the conceptual and practical 
separation of the activities that are conceptually related to the inter-agent coordination. These activities 
concern the participation in a coordinating process and define a supplement, which influences the core 
functionality of the agents. In this paper, we present an approach for this separation that is based on 
extending agent-oriented implementation modules. This allows the minimal-intrusive encapsulation and 
automation of inter-agent coordination. In addition, the discussed enhancement is attractive for MAS 
developers as it allows to modularize crosscutting concerns in MAS (see Section 2.2 1. 

This paper is structured as follows. In the following section, related work is outlined. In Section[3j a 
programming model for self-organization is outlined. The technological foundation for the encapsulation 
and automation of coordination activities is the activation of agent modules that is discussed in Section 
[4] The utilization of the programming model is exemplified in Section [5] before we conclude and give 
prospects for future work (see Section [6]). 



2 Related Work 

Agent technology provides tools and concepts for the construction of autonomous software elements 
and is a prominent grounding for the development of self-organizing applications [25]. Natural self- 
organizing systems are composed of autonomous system elements [19], e.g. particles and cells, and the 
coaction of these elements can be metaphorically resembled with autonomous software agents. 



2.1 Integrating Coordination Mechanisms 

The construction of self-organization, i.e. an adaptive, coordinating process that structures the config- 
urations of system elements, is based on two foundational types of implementation mechanisms |[3T| . 
First, generic interaction-level mechanisms have been proposed that allow to establish information flows 
between system elements (e.g. reviewed in ||8l). Among others, these mechanisms support the stochastic 
dissemination of information and the attenuation of outdated data. Secondly, adaptation-level mecha- 
nisms control the participation in interactions, the processing of the exchanged information, and affect 
the conclusive adjustments within software agents that result from the exchanged information. 

The encapsulation of interaction-level mechanisms is typically approached by dedicated communi- 
cation infrastructures and languages lfT2l . These are means to decouple software components but the 
coordination logic, e.g. when to interact and how to (locally) respond to interactions is blended in the 
control flow the system elements. In previous works, three foundational approaches have been followed 
to separate this control of the coordination from the control of the element functioning. First, special- 
ized agent architectures (e.g. ETll ) have been proposed that outsource coordination-related activities to 
specific modules. Secondly, the separation can be enforced by the execution infrastructure that is given 
by the utilized programming-language or middleware. An example is the outsourcing of coordination 
by using aspect-orientation [24]. Finally, approaches use networked elements to control the localized 
adjustments GoTl . 

In this paper, a coordination middleware layer is presented that extends the modularization-based ap- 
proaches (see above) to enable the separation and integration of coordination logic in generic agent archi- 
tectures. Preparing the integration in established, general-purpose agent-architectures allows to reuse the 
existing constructive knowledge and tool support that concerns these agent models, e.g. methodology- 
specific agent design techniques. The direct integration, by reusing agent-modularization concepts avoids 
the communication overhead of externalized approaches. 
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2.2 Crosscutting Concerns in Agent-Orientation 

Modularization enforces the decomposition of software systems into functional clusters with minimum 
overlapping functionality. These so-called core concerns are typically separated into different com- 
ponents or modules lfT7l . complex software systems often comprise additional crosscutting concerns, 
so-called aspects |[T5l , which are to be referenced from various modules. Prime examples are amongst 
others failure recovery, monitoring and logging. While these functionalities can be clustered in mod- 
ules, these will be referenced throughout the agent model. Thus the information when to invoke the 
functionality is spread and references are scattered. In this respect, the embedding of coordination is 
regarded as another crosscutting concern. When the logic how to adjust and interact, as to participate in 
a collaborative process, is encapsulated in specific module, the contained activities have to be frequently 
referenced in the agent model and these references with be scattered as well. Consequently, it is desirable 
to contains the functionality, as well as the context if it's invocation in a single agent element. 

The notion of crosscutting concerns for agent modularization has to date found minor attention. 
Numerous MAS infrastructures are build with object-oriented programming languages, thus Aspect- 
oriented Programming (AOP) lfT5l is one approach to embed crosscutting functionalities with additional 
programming language tool sets. In lfl6l . it is exemplified how AOP techniques can be used to modularize 
object-oriented agent models by encapsulating mobility related API calls that are available in the JADB^ 
agent platform and Garcia et al. [0, examined how AOP frameworks facilitate the realization of object- 
oriented agents. Examples of aspects in software agents are interaction, mobility and learning ifTOl . 



2.3 Agent Modularization Using the Example of BDI Agents 

Agent platforms [2] provide distributed middlewares for the construction of MAS. One prominent archi- 
tectural model is the Belief Desire Intention (BDI) architecture [ 20] that allows to express both longterm 
goal-directed objectives as well as reactivity. Following this architectural style, agents are structured as 
sets of Beliefs, Goals, and Plans. Beliefs contains the local knowledge of the agent about itself and the 
environment. Goals represent the objectives and plans are the executable means of agents. BDI-specinc 
reasoning engines control the agent execution. The currently active goals are deliberated and means-end 
reasoning is used to select plans for the achievement of goals. Modularity in terms of functional indepen- 
dent clusters has been introduced to BDI agents by the Capability concept |H1|4). Capabilities describe 
clusters of BDI concepts, i. e. Beliefs, Goals and Plans in a name-space. These enable the recursive 
inclusion of other capabilities (sub-capability). The interplay with a surrounding agent/capability (super- 
capability) is controlled by scoping rules. The visibility of the comprised elements is specified as well as 
the visibility of relevant events, generated outside of the capability. 

In l22l . a goal-centric modularization scheme, so-called Goal-Oriented Modularity, has been pro- 
posed. Modules encapsulate the information how sets of related goals can be satisfied. This enables a 
higher degree of encapsulation of behaviors.A behavior-based stance towards agent modularization is 
given in Q where role concepts encapsulate sets of beliefs, goals, plans and reasoning rules. In addition, 
the Enactment and deactment of roles at run-time is prepared. Modularization by policy-based intentions 
is proposed in [ 13]. Developers can explicitly declare in which context a module is to be activated. 

Due to the widespread, recognition, and practicability of the BDI agent model, the prototype real- 
ization of the here discussed coordination middleware (see Section [3} is based on this agent type. In 
this paper, the utilized enhancements to modularize crosscutting concerns are discussed in general (see 
Section [4]) and are then detailed for this particular agent model (see Section 4.1 1. 



~http://jade. tilab.com/ 



20 



Separating Agent-Functioning and Inter-Agent Coordination by Activated Modules 



3 The DECOMAS Architecture 



Within the SodekoVS research project 11291 , a programming model for distributed feedbacks among sys- 
tem elements is revised. A key objective of this framework is that the ability to self-organize is provided 
as an optional tool that development teams can integrate in their applications when needed. The aim is to 
enable the supplementation of self-organizing properties when the need for decentralized coordination 
of system elements is revealed. The foundational elements are a declarative configuration language IT331 
and an architectural model for the supplementation of externally prescribed inter-agent processes. Here, 
the configuration of self-organizing processes is not discussed. Details on the configuration language can 
be found in |[33l and a graphical representation of the process description is exemplified in the Sections 



5.1 and 5.2 to illustrate the intended application dynamics. 

This integration architecture follows a layered structure that is illustrated in Figure[T] The Application 
Layer contains the application functionality. Within this layer, agents act as providers of application- 
dependent functionalities. An underlying Coordination Layer controls the enactment of coordinating 
processes among (sub-)sets of agents. Coordination Media are conceptual entities that contain interaction 
mechanisms 0. Inside these media, these are realized by the utilization of communication infrastruc- 
tures (e.g. see [12J). The details of the interaction mechanisms are hidden by a generic publish/subscribe 
interface. The utilization of these media is shielded from the agent internals by intermediate Coor- 
dination Endpoints. These are associated to an agent and control the participation in a coordination 
process. Endpoints are enabled to observe and modify the execution of associated agents. The rationale 
is that Endpoints interact, via Media, in place of the associated agent and decide the local adjustments. 
Therefore, coordination-relevant activities, including adaptation-level mechanisms, are encapsulated (see 
Section |2T[). The operation of Endpoints are declaratively configured (see above). These declarations 



indicate which changes in the agent-internal configuration are significant for their participation in an 
inter-agent process. These events are then propagated via Media and processed by perceiving Endpoints. 
If these perceptions indicate the need for adjustments, these are made by triggering agent-internal be- 
haviors. Agent models are often capable to show concurrent conduct of behaviors and their scheduling 
is realized in the agent execution environment (e.g. see Section 4.1.1 1. Agents can be associated to 
more then one Endpoint, so the enactment of different processes is separated as well. A prototypical 
implementation of this architecture is reported in |32l and it's utilization is exemplified in |[34l . 
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Figure 1: The SodekoVS-Architecture to the embedding of decentralized coordination in MAS [34]. 
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4 Activating Agent Modules: Enabling Contributive Processing 



Agent-oriented software development is supported by comprehensive development environments. These 
provide execution middleware and programming languages for the utilization of agent-based implemen- 
tation concepts 0. It is desirable that agent developers can utilize these concepts throughout the whole 
development cycle, also when expressing cross-cutting concerns (see Section |2T2] ). Conventional mod- 
ules cluster functional concerns. These are typically used inside agents by explicitly referencing con- 
tained elements, e.g. dispatching (sub-)goals that are contained modules @. The aim of the proposed 
extension is to automate these references. Both the functionality and the information when it is to be 
invoked are contained in modules. These modules extend conventional agent modules, as modules are 
equipped with the ability of observe and modify the agent execution. These enhanced modules operate 
as autonomous actors that react to changes in the immediate context, i.e. the state of their host agent 
or super module. We name these modules co-efficient, since they register for contributive processing 
on certain agent reasoning events. The presented module concepts allows to compose agents as sets of 
independent actors. Besides the structuring of agent models, these modules facilitate the embedding of 
crosscutting mechanisms, like logging, failure recovery etc., to be automatically triggered. A example is 
the encapsulation of the monitoring of agent-behaviors in ||30l . A module observes the reasoning of the 
host agent and decides the recording, when the course of action is significantly adjusted. 

Figure [2] illustrates the conceptual model of a co-efficient agent module. Abstracting from specific 
agent architectures, we assume that the execution of an Agent Model is managed by a Reasoner, e.g. 
using reactive or deliberative mechanisms. The reasoning component processes Agent Reasoning Events 
that characterize the agent execution and reference agent elements which are modified. Examples are 
changes in agent-intern data structures (knowledge) or the execution of plans. A module concept allows 
to structure agents by containing sets of agent elements (e.g. (6l). Co-efficient modules extend these with 
two additional components. First, an Observation / Adjustment Component allows to observe and modify 
agent execution by registering for and dispatching reasoning events. This component makes use of 
platform-specific interfaces {Observation I Inducement). Secondly, developers specify an Event Mapping 
that describes which events are subject of observation as well as which events are to be dispatched to the 
reasoning mechanism. 
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Figure 2: Conceptual model of co-efficient agent modules. 

Figure [3] outlines the operating principle of a coefficient module. On agent start-up the module is 
registering {Observation interface) for the observation of a set of reasoning events in the surrounding 
agent (1). Subsequently, it is notified about these events (2) and the event mapping is interpreted to 
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infer which events to dispatch via the Inducement interface. These events reference agent elements (e.g. 
goals, beliefs) inside the module (3), or in the surrounding agent (4). The available reasoning events can 
be classified according to their effects on the agent execution. Events denote modifications of the agent 
state, the agent behavior, the agent model, or describe communicative activities. The concrete realization 



of these event categories depend on the utilized agent platform and architecture (e.g. see section 4.2 ) 
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Figure 3: Execution of a Co-Efficient Capability. 



4.1 Formalization of Coefficiency in Operational Semantics 



In Q20 | the BDI architecture has been defined by an abstract interpreter and a corresponding proof theory. 
This seminal work bridges the gap between the theory and practice of BDI agents and led to the logic- 
based Agentspectk(L) programming language [21]. Based on this language and further formalizations, 
the Operational Semantics for BDI agents have been given in IT3511 to support implementation and verifi- 
cation of BDI-based MAS. Here, we adopt these semantics to formally express the impact of co-efficient 



modules. Within BDI agents these are Coefficient Capabilities (CECs) (see Section 2.3 1) 



4.1.1 Operational Semantics for BDI Agents 

Operational Semantics are an established formalism to describe the semantics of programming lan- 
guages. The operation of programs is expressed by a transition relation between program configurations 
|[T8l . The complete specification of the Operational Semantics of BDI reasoning is given in ||35ll . In this 
section, key definitions are summarized that are used to specify the effects of crosscutting concerns on 
the execution of BDI agents (cf. Section 4.1.2) ). 



An agent configuration is defined as a a tuple < ag,C,M, T,s > 11351 . ag is the agent program, given 
by a set of beliefs and plans. C is a Circumstance that resembles the execution context of an individual 
agent. M is a tuple that characterizes the agent communication. T is a tuple that provides temporary 
information that is used by the reasoner and s is the current step in the reasoning cycle. 

In the following, these elements are detailed. The Circumstance C is defined as a tuple < I,E,A >, 
where the element / is a set of intentions {/,/', . . .}. An intention i is a stack of partially instantiated 
plans. £ is a set of events {(te, i), (te', /')>•• •}■ These are denoted as pairs (te,i) of a triggering event 
(te) and a related intention (/). When events result from the processing of other events, e.g. from the 
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achievement of (sub)goals, these follow-up events are associated to the currently active intention. An 
empty intention is denoted by T. In this respect, intentions represent different courses of actions. Their 
concurrent execution is controlled by the agent reasoner ||35ll . A is a set of actions that is available to the 
agent to modify the environment. 

The asynchronous communication of agents is characterized by the tuple M. The communicative 
abilities of agents are not influenced by CECs, therefore the management of communications is not 
discussed. Details can be found in ll35ll . 

Temporary information is kept in the tuple T. The elements < R,Ap,i,p ,e > provide volatile data 
to the reasoner. The set R is the set of plans that are relevant for the current event. These plans are 
capable to handle the event. Ap denotes the set of plans that are not only relevant but can be activated. 
The elements l,£,p refer to the current intention, event and applicable plan that are considered during 
one reasoning cycle. 

Finally, the current step in the reasoning cycle is given by the element s. Altogether the reasoning 
cycle is composed of nine steps s G {ProcMsg ,SelEv,RelPl ,ApplPl ,SelAppl ,AddIm, Sellnt ,ExecInt , 
Clrlnt}. These steps are: processing incoming messages, selecting an event to be handed, computing 
the relevant plans, computing the applicable plans, adding means, i.e. plans, to an intention, selecting an 
intention, executing an intention, clearing an intention OBI . 

CECs affect the selection of the handled events. Therefore, we summarize here the semantics of the 
original Event Selection rule (SelEv). This rule picks an event and marks it for further processing. BDI 
agents employ reactive planning they handle the events in E. Events are added to E by transition rules or 
elements of the general architecture outside the agent interpreter, e. g. belief updates. The rule SelEvl 
refers to the selection function S E that selects events from the set E. Selected events are removed from E 
and added to £ for further processing. If no event is to be handled, the rule SelEv2 skips directly to the 
intention execution that is initialized by the selection of an intention (Sellnt) [35]: 

s elE vl S E {C E ) = (te,i) 

(ag,C,M,T,SelEv) — ► (ag, C',M, T' , RelPl) 

where : C' E = CE\{(te,i}} 
Tg = {te,i) 



SelEv2 MCe)-{} 

(ag,C,M,T,SelEv) — ► (ag,C,M ,T, Sellnt) 

In order to handle selected events, the relevant and applicable plans are calculated and one applicable 
plan is selected. A group of rules is responsible to execute this applicable plan. Additional rules control 
the execution of different intentions. External events, i. e. events that are perceived and not generated by 
previous plan executions trigger the creation of a novel intention. These stacks of partially instantiated 
plans are added, removed, and selected for execution by dedicated transition rules OBI . 



4.1.2 The Operational Semantics for Co-Efficient Capabilities 

Co-efficient modules register themselves for agent observation (see Section |4]). These modules are no- 
tified when an event in a subset of reasoning events occurs. Upon these occurrences additional BDI 
reasoning events are dispatched in the surrounding agent. Realizations of these modules contain the con- 
figuration of (1) the events that are to be added by certain observations and (2) the execution context that 
permits the addition of the event. This configuration can be described as a set (K) of tuples (te s ,ted, A , k) : 
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• the element te s is a triggering event that is to be observed by the capability. The set of observed 
events is given by the set S (te s G S), which is a subset of the available reasoning events (S G E). 

• the element ted is the corresponding event that is to be added to the agent reasoner when te s 
is observed. The set of actuated events (D) is also a subset of the available reasoning events 
(fe d €D t D€E). 

• the element A denotes the logical location of event additions. Events {ted) can be placed in the 
currently active intention (i) or in a new intention (T; A G {i, T}). 

• the optional element K is a boolean expression that defines when the event ted is applicable to 
be added to the agent configuration. This expression takes into account the current agent state 
(ag,C,M,T) and denotes the context that permits the introduction of the additional event (ted). 
The expressiveness of these statements depends on the utilized agent platform. 

Three functions are introduced, which access this configuration, to simplify the semantics of agent 
state modifications. An auxiliary mapping function m(x) is assumed that maps triggering events to 
corresponding events (m : S — > D). According to the configurations in K this function returns the 
event(s) that are to be introduced (m(te s ) = ted). The function I : S,D — ► A returns the target intention 
(A) for an event mapping (S,D), i.e. two corresponding events (tested)- A can have two values and 
indicates either that the event is to be added to the current intention (A c ) or that the event is to be included 
in a new intention (A„). In the following, we also assume the availability of a platform specific function 
eval(te s ,ted) that extracts the agent execution context, looks-up the corresponding condition statement 
(jc) and evaluates the statement, i.e. returns a boolean (eval : S,D — ► {true, false}). The functions m 
and / are prescribed by the agent programmer. The given mapping defines the set of observed events and 
their counterparts, which are to be induced. For each of the latter events, its is also specified whether it is 
to be placed in the current intention or in a new one. New intentions initially contain only the triggering 
event and this placement initializes another concurrent course of actionfor the agent. 

Implementations of CECs are aware of the mapping function and dispatch the corresponding event 
in the surrounding agent. Afterwards the agent execution continues unaltered. Therefore, only the event 
selection rule SelEv is supplemented with another rule (SelEvCEC) that defines the the contribution of a 
CEC when events are selected that are in the set of observed events S. If te G" S, the unaltered selection 



rules (SelEvl,2) is used (cf. Section 4.1.1 1. The inserting of the event (ted G D) that corresponds the 
observed event m(te) into the agent circumstance (C' E ) is guarded by the annotated condition (k) that is 
evaluated for the currently handled event mapping (eval(te,m(te))). Events are inserted into the intention 
that is indicated by the function I (tested). The original event (te), which was selected for processing 
(Se(Ce) = (te,i)), is added to the temporal structure (7^) and subsequently processed by the reasoning 
cycle. This rule does not enforce immediate event processing. The additional event (ted) is added to the 
events that will be subsequently processed by the agent but the operation of the interpreter decides how 
agent execution proceeds. 

SelEvCEC S E (C E ) = (te,i) (teeS) 

(ag,C,M,T,SelEv) — > (ag,C',M,T',RelPl) 



where: 



, _ ( CEL){(m(te),l(te,m(te))}\{(te,i)} if eval (te,m(te)) = true ^, 
E \ CE\{(te,i}} otherwise e 



(te,i) 
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4.2 Prototype Realization 

The described mechanism has been implemented using the Jadex reasoning engind^J that provides an 
execution environment for BDI-style agents on top of arbitrary distributed systems middleware [3]. The 
Jadex platform allows implementations of a certain interface (jadex.run-time.ISystemEventListener), to 
be registered at individual agents. The Jadex Introspector and Tracer development tools, accompanying 
the Jadex distribution, use this mechanism to observe agent reasoning. Implementations of this interface 
can be registered for a specified set of reasoning events (defined in jadex.runtime.Systemevent) and an 
API allows to modify the BDI facilities of the surrounding agent via an API. 



4.3 Structuring Agents with Active, Context- Aware Modules 

In terms of comprehensibility and reusability, it is advisable to cluster distinguishable functionalities in 
modules. Capabilities contain libraries of BDI elements that can be referenced to reuse functionality. 
Besides, the goal-oriented and event-based processing of the reactive planning mechanism, can as well 
be exploited to handle functionalities that would be commonly understood as crosscutting concerns. 
For example, message based communication are encapsulated in ifTOll in an interaction aspect while the 
modularization of roles in a negotiation protocol is the prime example for BDI-based capabilities 



(cf. section 2.3 1. The proposed extension to the capability concept allows to automate the references to 
elements that are contained in capabilities. This facilitates information-hiding, as both the agent elements 
and the information when these are to be activated/modified are contained in a single entity. 

In addition, this approach facilitates the provision of additional, quasi contributive, processing of 
BDI reasoning events. The original handling of events leads to a series of subsequent events. For example 
the achievement of a goal may involve the successive achievement of subgoals. Besides this sequential 
execution path, which is controlled by the agent reasoner, the described mechanism allows to declare 
additional activities should be activated as well. These are caused by the activation of reasoning events 
(see equation[3]>. The authority of the reasoning mechanism, e.g. a BDI interpreter, is untouched and the 
contributive events integrate in the currently active or a in a concurrently executed intention. An example 
usage is the embedding of monitoring routines that decide the significance of agent state changes and 
communicate these to remote observers |3]3 as well as the embedding of assertion validations [28]. 

The here discussed activation of agent modules reveals another perspective on the modularization of 



agents. Besides functional clusters (see Section 2.3 1, agents can be structured as composites of context- 



aware actors that decide locally when to provide the contained functionalities. Despite the outlined 
benefits, the presented mechanism reduces the traceability of the agent actions, it makes it more difficult 
to trace the causes of specific agent actions. Since the additional events are handed over to the agent 
reasoner for subsequent processing, arbitrary agent events can be selected for inclusion. Subsequently, all 
events are similarly processed. Therefore, coefficient activities can be arbitrarily selected. However, the 
performance of the agent functionality is reduced by the coefficient inclusion of exhaustive processings. 



4.4 Construction of Coordination Endpoints 

A requirement for the realization of the Decomas architecture is the ability to associate Endpoints with 
agents and enable these endpoints to observe, reason about, and influence the agent execution (see Sec- 
tion]^]). The discussed coefficiency mechanism allows to construct Coordination Endpoints as agent mod- 
ules. Conceptually, this approach is attractive since the agent coordination is separated is represented as 
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an orthogonal aspect. The uncommunicative overhead, imposed by remote endpoints is avoided. Using 
coefficient agent modules, a generic Endpoint model has been conceived that abstracts from the utilized 
agent platform. 

This structure is illustrated in Figure [4] A Coordination Endpoint is composed of three (sub-) mod- 
ules. First, a Communication module contains the abilities to publish and perceive events that are sig- 
nificant for the inter-agent coordination. These modules exchange specific data elements (Coordination 
Information) and realize the Medium-specific information propagation. Endpoints contain also two in- 
terpreter elements. The Coordination Information Interpreter is responsible to process the perceived 
information and decides, based on a declarative configuration of the enacted coordination process ll33ll . 
the appropriate modifications of the host agent. This is a conventional agent module except that it affects 



the injection of modifications in the surrounding agent (see Section 4.1.2). The Agent State Interpreter 
is a coefficient module that registers for the observation of the surrounding host agent. The events of 
interest are given by a declarative model of the desired inter-agent coordination [33 ] that also contains 
the conditions and constraints that control the publication of agent-internal events and data. Using coef- 
ficiency, the observation and affection of publications is realized as an autonomous background process 
inside agents. 
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Figure 4: Excerpt from [32] that illustrates the structure of Coordination Endpoints. 



5 Shoaling Glassfishes: Decentralized (Web) Service Management 

Distributed software systems imply an administrative overhead that originates in the manual maintenance 
of computational infrastructure, e.g. the provision of server installation and server deployments in Ser- 
vice Oriented Architectures. The reduction of this overhead in dynamic environments, where request 
loads and resource usages fluctuate, is a prominent research topic lfl4ll . Often it is necessary to augment 
existing middlewares with adaptive mechanisms ifTTTl . 

Here, we outline the development of a decentralized, agent-based management framework for the 
maintenance of distributed software infrastructures. Figure [5]illustrates the conceptual architecture. Ser- 
vices are deployed on application server instances (App. Server). These servers reside on different 
Server-Clusters, i.e. are distributed in different computing / data centers. Service endpoints and applica- 
tion servers are managed by remote software agents (Agent-based Management). These agents monitor 
and manipulate the configurations of services and servers. The management by agents is realized with 
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the SUN Appserver Management EXtensionsn(AMX), a generic API to control J2EE Application Server 
configurations. Managers of application servers are bound to specific installations, while service end- 
points are free to reallocate to different servers and change their service offer. Agents are equipped 
with plans for the deployment and undeployment of services. Unknown of service configurations can 
be fetched from remotely accessible repositories. Service consumers (cf . figure [5} top-left) invoke web 
services. The dynamics of service deployments and server utilizations are hidden by Service Brokers. 
These maintain local registries of the physical locations of service deployments. Therefore, clients can 
retrieve the addresses of the current deployments from the static locations of the Brokers. In addition, 
the Brokers load-balance the service utilizations. 
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Figure 5: Decentralized, agent-based service management framework. 



This prototype architecture has been realized with the Jadex agent framework (cf. Section 4.2 1. It 
prepares the agent-based management of service infrastructures as agents are capable to administrate 
services and servers, i.e. to deploy / undeploy services. The server management has been tested with 
the freely available G/a^/j^/j^] application server. The actual coordination logic is supplemented with 
the systemic programming model that is discussed in Section|3] This management concerns two aspects 
of the dynamic deployment of (web) services. First, the allocation of physical servers is balanced to 
maintain averaged utilization levels. Servers are associated with preferential workload-levels. Based 
on the communication of available capacities, services are moved to ensure that all servers are in their 
preferred operational condition. Secondly, the adjustment of static service deployments is automated 
to meet dynamically changing service workloads. The deployments of highly-demanded services are 
reinforced and less-demanded services are reduced. 



4 https://glassfish.dev.java.net/javaee5/amx/index.html 
5 Version 2 (ur2-b04), https://glassfish.dev.java.net/ 
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5.1 Server Utilization Management 

The aim of the utilization management is to maintain a preferential number of service deployments on 
servers. The rational is, that servers are dimensioned for a specific utilization. Therefore, the maintenance 
of several underutilized servers is a waste of resources, e.g. energy |[T4ll . when the services could be 
handled by a single server that is properly utilized. The decentralized management is based on the 
publication of capacities by underutilized servers and services are attracted to servers that are almost 
well utilized. 

The dynamics of the adaptive placement of services is illustrated in Figure [6] (I). The variable Un- 
derloaded describes the number of servers that are below their intended utilization. This utilization is 
maintained by a balancing feedback loop (-). A Coordination Endpoint determines whether the server 
is underutilized or not (a logical condition, defined on the set of agent beliefs). The Endpoints within 
underloaded servers publish the availability of capacities (j8). These publications propagate in a Coor- 
dination Medium to the Coordination Endpoints in Service Endpoint agents (Moveable). These decide 
whether to change the service deployment, i.e. move to another server, or not. Movements affect the 
system-wide rate of (re-)deploying agents (Server Change) and consequently influences the number of 
(re-)deployed services. Since these deployment actions were caused by the availability of resources, the 
number of underloaded servers decreases. 

Figure|6](II) shows simulation results for the described coordinating process. Two application servers 
are initialized with slightly different workloads. Servers are configured to host up to 5 services. The 
availability of server capacity gradually spreads in the system and services are (re-)deployed. Figure [6] 
(A) denotes the movement of services that is carried out be their un- and (re-)deployment. 
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Figure 6: Server utilization management: The dynamics of the management (I) and a simulation snapshot 
(II). The simulation results relate the deployments per server (ll.a) to all service registrations (Il.b). 



5.2 Balancing Service Deployments 

The adaptive reinforcement of service deployments, balanced with fluctuating request loads, is based on 
the publications of demand changes by Broker agents. Using the coordination architecture, the mea- 
surement and interpretation of demand changes is encapsulated in Endpoint modules. These publish 
significant changes and upon the reception of these information, the Endpoints of Service agents decide 
whether to adjust the local deployment or not. 



/. Sudeikat & W. Renz 



29 



The dynamics of this adaptive process is illustrated in Figure [7J (I) Requesters increase, with a fluc- 
tuating rate, the number of Service Requests that the system has to work off. The amount of requests 
causally influences the measured Service Demand. The Allocated variable denotes the number of agents 
that offer services. Service Brokers are supplemented with the ability to publish (a) significant changes 
in request workloads (Service Reinforcement). The publications affect that agents consider an adjust- 
ment of their current service offer (Changing Service Allocation). The additional behaviors, required to 
participate in this process, are implemented in Coordination Endpoints. Within Service Brokers, these 
decide the significance of workload changes and in Service Endpoints, these decide whether to change 
deployments or not. 

Figure [7] (II) shows simulation results for 10 virtual application servers (domains) that run on a 
Glassfish installation. Each of them is configured to host a maximum of 5 web service implementations. 
An additional constraint is that every service type is only deployed once on every domain. Initialized 
with an arbitrary configuration of service deployments, the system is exposed to a sudden workload of 
service type 1. The publication of this demand change enforces that Service Endpoints locally adjust and 
switch their deployments. Details on the integration of this coordination model and the declaration of 
agent-internal data to be communicated, including code fragments, can be found in lf34ll33Tl . 
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Figure 7: J2EE (Web-)Service management: Balancing Service Workload. 



6 Conclusions 

In this paper, we presented an architecture for the integration of decentralized, self-organizing coordina- 
tion in MAS. This architecture provides a middleware layer that contains coordination mechanisms and 
automates their invocation. A key design concern is that the architecture can be integrated in established 
agent architectures and that coordination can be supplemented to functional MAS. This allows that self- 
organization can be supplemented to conventionally developed MAS. The accomplishment of this design 
objective requires that invocations can be supplemented without affecting the structure of the original, i.e. 
not self-organizing, MAS. This has been approached with the concept of activated agent modules. Their 
generic structure and operating principle is discussed. Their implementation is outlined and formalized 
for a particular agent architecture. The utilization of the coordination framework is exemplified for the 
management of service oriented computing infrastructures. Future work comprises the programming 
language techniques that are used to control the execution of Media and Endpoint elements. Ongoing 
work concerns the revision of a declarative configuration approach [33] to integrate the prescriptions of 
self-organizing processes in MAS development frameworks. 



30 



Separating Agent-Functioning and Inter-Agent Coordination by Activated Modules 



Acknowledgment 

We cordially thank Rafael H. BordinQfrom the Institute of Informatics at the Federal University of Rio 
Grande do Sul for discussing and reviewing the formalization of the endpoint operation principle that is 
discussed in Section 4. 1 We also thank the Distributed Systems and Information Systems (VSIS) group 
at Hamburg University, particularly W. Lamersdorf, L. Braubach, A. Pokahr, and A. Vilenica for helpful 
discussion. The SodekoVS-project is funded by the Deutsche Forschungsgemeinschaft (DFGQ 



References 

[1] E. Bonabeau, M. Dorigo & G. Theraulaz (1999): Swarm Intelligence: From Natural to Artificial Systems. 
Santa Fe Institute Studies on the Sciences of Complexity. Oxford University Press. 

[2] Rafael Bordini, Lars Braubach, Mehdi Dastani, Amal El Fallah Seghrouchni, Jorge Gomez-Sanz, Joao Leite, 
Gregory O'Hare, Alexander Pokahr & Alessandro Ricci (2006): A Survey of Programming Languages and 
Platforms for Multi- Agent Systems. In: Informatica 30, pp. 33^)4. 

[3] L. Braubach, A. Pokahr & W. Lamersdorf (2005): Jadex: A BDI Agent System Combining Middleware and 
Reasoning. In: Software Agent-Based Applications, Platforms and Development Kits, Birkhauser. 

[4] Lars Braubach, Alexander Pokahr & Winfried Lamersdorf (2005): Extending the Capability Concept for 
Flexible BDI Agent Modularization. In: Proc. of PROMAS-2005. 

[5] Yuriy Brun, Giovanna Marzo Serugendo, Cristina Gacek, Holger Giese, Holger Kienle, Marin Litoiu, Hausi 
Midler, Mauro Pezze & Mary Shaw (2009): Software Engineering for Self-Adaptive Systems, chapter Engi- 
neering Self-Adaptive Systems through Feedback Loops, pp. 48-70. Springer- Verlag, Berlin, Heidelberg. 

[6] Paolo Busetta, Nicholas Howden, Ralph Ronnquist & Andrew Hodgson (2000): Structuring BDI Agents in 
Functional Clusters. In: ATAL '99, Springer, pp. 277-289. 

[7] Mehdi Dastani, M. Birna van Riemsdijk, Joris Hulstijn, Frank Dignum & John-Jules Ch. Meyer (2005): 
Enacting and Deacting Roles in Agent Programming. In: Lecture Notes in Computer Science, 3382. 

[8] T. DeWolf & T. Holvoet (2007): Decentralised Coordination Mechanisms as Design Patterns for Self- 
Organising Emergent Systems. In: Engineering Self-Organising Systems, 4335/2007, pp. 28-49. 

[9] Alessandro Garcia, Uir Kulesza & Carlos Lucena (2005): Aspectizing Multi-agent Systems: From Architec- 
ture to Implementation. In: Lecture Notes in Computer Science, 3390, pp. 121 - 143. 

[10] Alessandro F. Garcia, Carlos J. P. de Lucena & Donald D. Cowan (2004): Agents in object-oriented software 
engineering. Softw. Pract. Exper. 34(5), pp. 489-521. 

[11] D. Garlan, S.-W. Cheng, A.-C. Huang, B. Schmerl & P. Steenkiste (2004): Rainbow: architecture-based 
self-adaptation with reusable infrastructure. Computer 37 '(10), pp. 46-54. 

[12] David Gelernter & Nicholas Carriero (1992): Coordination languages and their significance. Commun. 
ACM 35(2), pp. 97-107. 

[13] Koen Hindriks (2008): Modules as Policy-Based Intentions: Modular Agent Programming in GOAL. In: 
Programming Multi-Agent Systems, 4908/2008, Springer Berlin / Heidelberg. 

[14] Rajarshi Das Jeffrey, O. Kephart, Charles Lefurgy, Gerald Tesauro, David W. Levine & Hoi Chan (2008): 
Autonomic Multi-Agent management of Power and Performance in Data Centers. In: Proc. of the 7th Int. 
Conf. on Autonomous Agents and Multiagent Systems (AAMAS 2008), pp. 107-114. 

[15] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier & 
John Irwin (1997): Aspect-Oriented Programming. In: Proc. ofECOOP, Springer. 



6 R.Bordini@inf. ufrgs.br 
7 http://www.dfg.de 



/. Sudeikat & W. Renz 



31 



[16] Cidiane Lobato, Alessandro Garcia, Alexander Romanovsky, Cludio Sant'Anna, Uir Kulesza & Carlos Lu- 
cena(2004): Mobility as an Aspect: The AspectM Framework. In: Proceedings of the 1st Brazilian Workshop 
on Aspect-Oriented Software Development WASP04. 

[17] D. L. Parnas (1972): On the criteria to be used in decomposing systems into modules. Commun. ACM 
15(12), pp. 1053-1058. 

[18] Gordon D. Plotkin (2004): The origins of structural operational semantics. Journal of Logic and Algebraic 
Programming 60-61, pp. 3-15. Available at |http : //dx . doi . org/10 . 1016/ j . j lap . 2004 . 03 . 009| 

[19] Mikhail Prokopenko (2008): Advances in Applied Self-organizing Systems, chapter Design vs. Self- 
organization, pp. 3-17. Springer London. 

[20] A. S. Rao & M. P. Georgeff (1995): BDI-agents: from theory to practice. In: Proceedings of the First Int. 
Conference on Multiagent Systems. Available at |citeseer . ist .psu. edu/rao95bdi .html 

[21] Anand S. Rao (1996): AgentSpeak(L): BDI agents speak out in a logical computable language. In: Proceed- 
ings of the 7th European workshop on Modelling autonomous agents in a multi-agent world, pp. 42-55. 

[22] M. Birna van Riemsdijk, Mehdi Dastani, John-Jules Meyer & Frank de Boer (2006): Goal-Oriented Mod- 
ularity in Agent Programming. In: AAMAS '06: Proceedings of the fifth international joint conference on 
Autonomous agents and multiagent systems, ACM Press. 

[23] Mazeiar Salehie & Ladan Tahvildari (2009): Self-adaptive software: Landscape and research challenges. 
ACM Trans. Auton. Adapt. Syst. 4(2), pp. 1^42. 

[24] Linda M. Seiter, Daniel W. Palmer & Marc Kirschenbaum (2006): An aspect-oriented approach for modeling 
self-organizing emergent structures. In: SELMAS '06: Proceedings of the 2006 international workshop on 
Software engineering for large-scale multi-agent systems, ACM Press, New York, NY, USA, pp. 59-66. 

[25] G. D. M. Serugendo, M. P. Gleizes & A. Karageorgos (2006): Self-Organisation and Emergence in MAS: An 
Overview. In: Informatica, 30, pp. 45-54. 

[26] G. Di Marzo Serugendo & J. Fitzgerald (2009): Designing and Controlling Trustworthy Self-Organising 
Systems. Perada Magazine . 

[27] Amit Shabtay, Zinovi Rabinovich & Jeffrey S. Rosenschein (2006): Behaviosites: a novel paradigm for 
affecting Distributed Behavior. In: Proceedings ofESOA'06, pp. 23-39. 

[28] Jan Sudeikat, Lars Braubach, Alexander Pokahr, Winfried Lamersdorf & Wolfgang Renz (2006): Validation 
of BDI Agents. In: Programming Multi- Agent Systems (ProMAS 2006), number 4411 inLNAI, pp. 185-200. 

[29] Jan Sudeikat, Lars Braubach, Alexander Pokahr, Wolfgang Renz & Winfried Lamersdorf (2009): Systemati- 
cally Engineering SelfOrganizing Systems: The SodekoVS Approach. EASST 17. ISSN 1863-2122. 

[30] Jan Sudeikat & Wolfgang Renz (2007): Monitoring Group Behavior in Goal-Directed Agents using Co- 
Efficient Plan Observation. In: Agent-Oriented Software Engineering VII, 4405/2007, pp. 174-189. 

[31] Jan Sudeikat & Wolfgang Renz (2008): Applications of Complex Adaptive Systems, chapter Building Com- 
plex Adaptive Systems: On Engineering Self-Organizing Multi-Agent Systems, pp. 229-256. IGI Global. 

[32] Jan Sudeikat & Wolfgang Renz (2009): DeCoMAS: An Architecture for Supplementing MAS with Systemic 
Models of Decentralized Agent Coordination. In: Proc. of the 2009 IEEE/WIC/ACM Int. Conf. on Intelligent 
Agent Technology, IEEE Computer Society Press, pp. 104-107. 

[33] Jan Sudeikat & Wolfgang Renz (2009): MASDynamics: Toward Systemic Modeling of Decentralized Agent 
Coordination. In: K. David & K. Geihs, editors: Kommunikation in Verteilten Systemen, pp. 79-90. 

[34] Jan Sudeikat & Wolfgang Renz (2009): Programming Adaptivity by Complementing Agent Function with 
Agent Coordination: A Systemic Programming Model and Development Methodology Integration. Commu- 
nications ofSIWNl, pp. 91-102. ISSN 1757-4439. 

[35] Renata Vieira, Alvaro Moreira, Michael Wooldridge & Rafael H. Bordini (2007): On the formal semantics of 
speech-act based communication in an agent-oriented programming language. J. Artif. Int. Res. 29(1), pp. 
221-267. 



